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Software 

Human-Computer 
Interaction  Software: 
Lessons  Learned, 
Challenges  Ahead  - 


Gerhard  FI  achat.  University  of  Colorado  at  Boulder 


HCI  software  should 
augment  human 
Intelligence.  Despite 
the  progress  that  has 
been  marie  over  the 
last  few  years,  the  big 
challenge  Is  to  create 
truly  cooperative 
problem-solving 
systems. 


Writing  good  software  for  human- 
computer  interaction  is  a  major 
challenge.  This  very  new  field  is 
based  on  three  developments:  Powerful 
workstations  with  bitmapped  screens  and 
pointing  devices  provide  the  new  techno¬ 
logical  base.  Innovative  applications  have 
drawn  attention  to  the  computer’s  interac¬ 
tive,  rather  than  its  computational,  capabili¬ 
ties.  The  complexity  of  today’s  software  has 
made  better  communication  techniques  a 
necessity,  not  a  luxury. 

Good  HCI  is  important  for  the  products 
that  the  software  engineer  designs  and  im¬ 
plements  for  users,  but  it  is  equally  impor¬ 
tant  for  software  engineers  themselves. 
They  have  to  design ,  understand,  and  main¬ 
tain  complex  artifacts  that  are  opaque  and 
very  difficult  to  deal  with.  Software  engi¬ 
neers  and  programmers  have  a  stake  in  im¬ 
proving  today's  environments. 


Software  design  as  a 
communication  process 

Having  spent  the  last  decade  building 
knowledge-based  systems,  improving 
human-computer  interaction,  and  explor¬ 
ing  the  nature  of  design  processes,  my  col¬ 
leagues  and  I  are  convinced  that  current 
life-cycle  models  of  software  engineering 
are  inadequate  for  most  of  today’s  comput¬ 
ing  problems.1  They  are  inadequate  be¬ 
cause  they  rest  on  the  assumption  that  prob¬ 
lem  requirements  can  be  stated  precisely  at 
the  beginning  of  a  project  and  that  com¬ 
plete  specifications  and  an  implementation 
can  be  derived  from  them  through  formal 
manipulations. 

Software  engineering  is  a  design  activity. 
Most  design  problems  are  ill-structured3 
and  must  be  solved  by  exploration  and  error 
elimination,  considered  the  foundation  of 
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all  scientific  activity  by  the  philosopher 
Karl  Popper.3  This  is  especially  true  for 
HCI  software:  There  are  no  complete  HC1 
theories.  The  problem  is  ill-structured, 
and  so  many  of  the  methods  and  tools  de¬ 
veloped  for  traditional  software-engi¬ 
neering  problems  are  of  little  use  for  HCI 
software. 

Ill-structured  problems  are  also  charac¬ 
terized  by  design  instabilities  and  the  need 
for  frequent  redesign.  The  main  goal  of 
HCI  software  is  not  to  develop  a  correct 
implementation  of  given  specifications 
but  to  develop  an  effective  solution  that 
corresponds  to  real  needs.  Specification 
correctness  in  this  context  is  not  a  mean¬ 
ingful  concept  because  it  implies  a  precise 
specification  of  intent,  which  is  seldom 
available. 

Unless  we  match  our  paradigms  and 
methods  to  ill-structured  problems,  the 
implementation  disasters  of  the  1960s  will 
be  succeeded  by  the  design  disasters  of  the 
1980s.  We  need  effective  exploratory  pro¬ 
gramming  environments  and  rapid-proto¬ 
typing  tools  that  support  iterative,  evolu¬ 
tionary  design. 

The  best  paradigm  for  creating  HCI  soft¬ 
ware  is  a  communication  model1  and  a 
rapid-prototyping  approach  that  supports 
the  coevolulion  of  specification  and  im¬ 
plementation.4  Communication  between 
customers,  designers,  and  implementers 
and  between  humans  and  the  knowledge 
base  that  describes  the  emerging  product 
is  crucial. 

Our  work  at  the  University  of  Colorado 
at  Boulder  centers  on  knowledge-based 
systems  that  enhance  and  support  com¬ 
munication.  When  we  write  HCI  software, 
we  define  what  the  computer  will  do  and 
what  humans  will  and  can  do.  We  also 
make  assumptions  about  what  they  want  to 
do.  It  is  this  human  element  that  distin¬ 
guishes  HCI  software: 

•  Humans  are  individuals  with  different 
talents,  goals,  knowledge,  and  prefer¬ 
ences. 


•  Humans  are  moving  targets,  not  static 
objects.  They  start  as  novices  and  may  re¬ 
main  in  this  class,  but  they  may  also  be¬ 
come  casual  or  expert  users. 

HCI  software  design  must  start  with  the 
human  as  a  fix  point.  Humans  do  not  have 
three  hands,  and  our  designs  must  take 
this  into  account  —  users  cannot  keep  two 
hands  on  a  keyboard  and  one  on  a  mouse. 
HCI  software  should  acknowledge  human 
weaknesses  (limited  short-term  memory 
and  execution  errors)  and  exploit  human 
strengths  (a  powerful  information-pro- 
cessinr  and  visual  system). 

Knowledge-based  HCI 

Our  research  has  three  dimensions: 
theory  development,  engineering  con¬ 
struction,  and  empirical  studies.  The  goal 
of  theory  development  is  to  understand 
how  human  cognition  and  design  capa¬ 
bilities  result  from  an  interplay  between 
mental  processes  and  external  computa¬ 
tional  and  memory  aids.  The  purpose  of 
engineering  construction  is  to  design  and 
develop  the  desired  artifacts.  The  empiri¬ 
cal  research  examines  how  people  per¬ 
form  tasks  using  the  artifacts  in  a  natural 
setting. 

The  primary  application  of  our  research 
has  been  the  creation  of  knowledge-based 
HCI  software  to  run  on  high-functionality 
systems  in  support  of  cooperative  problem 
solving. 

Architecture.  Effective  HCI  ismore  than 
creating  attractive  displays:  You  must  give 
the  computer  a  considerable  body  of 
knowledge  about  the  world,  users,  and 
communication  processes. 

However,  the  use  of  knowledge-based 
systems  today  is  limited  severely  by  the 
communication  bottleneck  in  the  narrow 
channel  between  the  user  and  the  system. 
A  good  user  interface  is  vital  to  a  knowl¬ 
edge-based  system,  but  it  has  little  use  if  its 
sophisticated  graphical  facilities  lack  rich, 
supporting  information  structures. 


Knowledge-based  facilities  have 
elaborate,  interactive  graphical  interfaces 
supported  by  specialized  viewers  and  in¬ 
formation-management  systems. 

To  support  these  systems,  we  have  devel¬ 
oped  a  model,  illustrated  in  Figure  1 .  Our 
system  architecture  reflects  two  major  de¬ 
partures  from  traditional  approaches: 
The  use  of  windows,  menus,  and  pointing 
devices  widens  the  explicit  communi¬ 
cation  channel,  and  shared  knowledge  es¬ 
tablishes  an  implicit  communication 
channel. 

Explicit  channel.  Large  bitmapped 
screens  with  windows,  menus,  pointing 
devices,  and  speech  output  and  input  have 
widened  the  explicit  channel  between  the 
user  and  computer  dramatically.  Tnese 
technologies  are  necessary  but  by  no 
means  guarantee  good  HCI. 

Exploiting  these  technologies  to  benefit 
the  user  requires  a  deeper  understanding 
of  psvchological  principles  —  for  ex¬ 
ample,  the  difference  between  recall  and 
recognition  memory,  by  which  menu  sys- 


Figure  1.  Architecture  tor  knowledge- 
based  human-computer  interaction. 
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tcms  should  be  evaluated.  We  must  also 
take  into  account  the  nature  of  different 
tasks  and  the  user's  abilities. 

The  design  space  of  the  explicit  channel 
is  huge,  largely  unstructured,  poorly  un¬ 
derstood,  and  inadequately  supported  by 
tools.  It  should  therefore  come  as  no  sur¬ 
prise  that  even  with  improved  technical 
capabilities  many  HCI  systems  are  still 
modeled  on  teletype  interaction. 

Implicit  channel.  When  communication 
is  based  on  shared  knowledge  structures,  it 
is  not  necessary  to  exchange  all  informa¬ 
tion  between  the  user  and  system  expli¬ 
citly.  Figure  1  lists  four  knowledge 
domains  necessary  for  implicit  communi¬ 
cation: 

1.  Problem  domain.  Intelligent  be¬ 
havior  builds  on  large  amounts  of  knowl¬ 
edge  about  specific  domains.  This  knowl¬ 
edge  constrains  the  number  of  possible 
actions  and  describes  reasonable  goals 
and  operations.  We  can  infer  the  user's 
goals  and  intentions  if  we  understand  the 
correspondence  between  the  system's 
primitive  operations  and  the  concepts  of 
the  task  domain.  If  the  computer  has  a 
model  of  the  problem  domain's  abstrac¬ 
tions,  communication  between  the 
human  and  the  problem  domain  is 
feasible. 

2.  Communication  processes.  The  in¬ 
formation  structures  that  control  commu¬ 
nication  should  be  made  explicit  so  the 
user  can  manipulate  them.  Safe,  explora¬ 
tory  environments  should  be  supported 
(for  example,  with  undos,  redos,  and  his¬ 
tory  lists).  User  and  computer  should 
communicate  by  writing  on  a  shared  dis¬ 
play  or  by  referring  to  something  already 
on  the  display.  This  interreferential,  I/O 
model  (for  example,  as  supported  by  the 
Symbolics  presentation  system)  supports 
dialogue  rather  than  issuing  isolated  mes¬ 
sages. 

3.  Communication  partner.  The  user  of 
a  system  does  not  exist;  there  are  many 
kinds  of  users,  and  an  individual’s  require¬ 
ments  change  with  experience.  Adaptive 
systems  change  their  behavior  according 
to  the  needs  of  different  users.  Unless  the 
system  has  a  model  of  the  user,  it  is  im¬ 
possible  for  it  to  relate  descriptions  of  new 
systems  to  the  existing  knowledge  of  in¬ 
dividual  users. 


4.  Common  problems  and  in¬ 
structional  strategies.  If  the  system  is  to  be 
a  good  coach  or  teacher  and  notjust  an  ex¬ 
pert,  it  must  incorporate  instructional 
strategies  based  on  pedagogical  theories 
and  exploit  the  knowledge  contained  in  its 
model  of  the  user.  For  the  same  reason,  an 
intelligent  support  system  should  know 
when  to  interrupt  a  user. 

Object-oriented  architectures.  Our  sys¬ 
tems  use  an  object-oriented  architecture, 
which  has  been  shown  to  be  well-suited  to 
interface  construction.  In  this  model,  the 
user  communicates  with  the  sy  stem,  which 
is  represented  on  the  screen  as  a  world 
composed  of  active  objects.  Each  screen 
object  has  its  visual  representation  (which 
defines  its  appearance  and  its  relation  to 
other  screen  objects)  and  a  functional  role 
(which  governs  its  behavior) . 

The  principles  of  object-oriented  design 
—  inheritance,  flexibility,  extensibility, 
and  modularity  —  support  new  program¬ 
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ming  methodologies  that  encourage  de¬ 
signing  for  reusability  and  redesign,  such 
as  differential  programming  and  pro¬ 
gramming  by  specialization  and  analogy. 
Object-oriented  architectures  provide 
substantial  support  for  interface  design. 

Domain  communication.  Most  users  are 
experts  in  some  problem  domain, 
whether  it  be  physics  or  music.  The  com¬ 
puter  is  a  generalist;  its  generality  means  it 
can  support  all  knowledge  workers.  But 
domain  experts  are  not  interested  in 
learning  the  computer’s  languages;  they 
simply  want  to  use  it  to  solve  problems  and 
accomplish  tasks. 

To  shape  the  computer  into  a  truly  use¬ 
ful  medium,  we  have  to  make  it  invisible 
and  let  users  work  directly  on  their  prob¬ 


lems  and  their  tasks.  To  do  this  we  must 
“teach''  the  computer  the  experts'  lan¬ 
guages  by  endowing  it  with  the  abstrac¬ 
tions  of  different  application  domains. 

The  principle  of  human  problem-domain 
communication1  abstracts  the  important 
operations  and  objects  of  a  domain  and 
builds  them  into  the  computing  environ¬ 
ment.  This  lets  the  user  operate  with  per¬ 
sonally  meaningful  abstractions.  It  is  im¬ 
portant  not  to  lose  the  semantics  of  the 
domain  by  reducing  it  to  oversimplified 
data  structures. 

WLisp,  our  user-interface  toolkit,6  and 
two  systems  called  Framer  and  Crack  sup¬ 
port  human  problem-domain  communi¬ 
cation  in  the  areas  of  interface  and  kitchen 
design.  People  can  use  these  svstems  to  do 
programming  by  constructing  artifacts  in 
the  domain  instead  of  writing  statements 
in  a  programming  language.  Our  experi¬ 
ments  have  shown  that  people  who  use 
these  environments  had  a  sense  of  accom¬ 
plishment  because  they  created  their  own 
impressive  version  of  something  that 
works  but  was  not  difficult  to  build. 

Framer  and  Crack,  described  in  the  box 
on  pp.  48-49  are  design  environments 
(with  embedded  construction  kits):  They 
provide  a  set  of  building  blocks  that  model 
a  problem  domain.  The  building  blocks 
define  a  design  space  ( the  set  of  all  designs 
that  can  be  created  by  combining  these 
blocks)  and  a  design  vocabulary.  The 
advantage  of  design  environments  is  that 
they  eliminate  several  prerequisite  skills, 
thus  letting  users  spend  much  more  time 
working  in  their  area  of  interest. 

The  d isadvan  tage  is  that  these  design  en¬ 
vironments  are  effective  in  only  one  area. 
But  this  limitation  affects  all  knowledge- 
based  systems,  and  human  expertise  is  also 
restricted  to  specific  domains.  The  chal¬ 
lenge  for  computer  systems  is  to  create 
these  design  spaces  for  many  domains  and 
to  organize  this  huge  set  so  users  can  find 
the  abstractions  they  need. 

Reuse  and  redesign.  Software  environ¬ 
ments  must  support  design  method¬ 
ologies  whose  main  activity  is  not  only  the 
generation  of  new  programs  but  also  the 
maintenance,  integration,  modification, 
and  explanation  of  existing  ones. 

A  construction  kit  with  many  general 
building  blocks  supports  reuse  and  rede- 
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sign  by  providing  stable  abstractions.  The 
user-interface  tools  of  Smalltalk,  the  Lisp 
machines,  and  Wlisp  have  undergone  a 
long  evolutionary  development.  They  are 
based  on  abstractions  about  the  domain  of 
interface  design  and  constitute  a  partial 
theory  of  one  class  of  user  interfaces.  The 
evolutionary  development  of  such  a 
theory,  driven  by  tests  of  the  abstractions’ 
validity  in  several  applications,  is  a  prereq¬ 
uisite  for  the  development  of  a  system  that 
supports  reuse  and  redesign. 

However,  standard  programming  lan¬ 
guages  offer  only  a  few  primitives  for  HCI 
(read,  write,  and  format).  These  primi¬ 
tives  are  conceptually  based  on  a  linear 
stream,  not  a  two-dimensional  screen .  So  it 
is  a  huge  effort  to  build  the  HCI  part  of  an 
application  because  the  designer  has  to 
build  it  from  low-level  components. 

On  the  other  hand,  functionally  rich  en¬ 
vironments  offer  hundreds  and  thou¬ 
sands  of  abstractions,6  substrates  for  HCI 
(different  classes  of  windows,  support  for 
interreferentia)  I/O),  and  screen-layout 
tools.  Such  systems  reduce  the  size  of  the 
application  system  substantially.  The 
major  cost  of  such  systems  is  that  the  de¬ 
signer  must  learn  and  understand  the  ab¬ 
stractions,  but  this  cost  is  incurred  only 
once  per  designer. 

Intelligent  support  systems.  High-func¬ 
tionality  systems  are  not  without  prob¬ 
lems,  however.  Our  informal  empirical 
studies  have  shown  that: 

•  Users  do  not  know  that  tools  exist.  It  is 
very  difficult  for  a  novice  or  casual  user  to 
build  a  mental  model  of  the  capabilities  of 
a  high-functionalitv  system.  Without  such 
a  model,  users  are  unaware  of  tools  that 
might  be  relevant  to  their  tasks.  A  passive 
help  system  is  no  help  in  this,  because  to 
ask  a  question  the  user  must  know  enough 
to  know  what  is  not  known!  Active  help  sys¬ 
tems,  critics,  and  browsing  tools6  let  users 
explore  a  system  and  point  out  useful  in¬ 
formation. 

•  Users  do  not  know  how  to  access  tools. 
Knowing  that  something  exists  does  not 
guarantee  that  you  know  how  to  find  it 

•  Users  do  not  know  when  to  use  tools. 
While  each  system  feature  may  have  a  sen¬ 
sible  design  rationale  from  the  system 
engineer's  viewpoint,  this  rationale  is  fre¬ 
quently  beyond  the  user's  grasp.  Users  do 


not  understand  which  commands  are 
basic  and  which  are  advanced,  nor  do  they 
understand  that  the  options  represent 
different,  generalized  interaction  styles. 

•  Users  do  not  understand  the  results 
that  tools  produce.  Visualization  tools  and 
explanation  components  address  this 
problem. 

•  Users  cannot  combine,  adapt,  and 
modify  tools  according  to  their  needs. 
Even  after  all  the  other  problems  are  over¬ 
come,  in  many  cases  the  tool  does  not  do 
exactly  what  the  user  wants.  The  user 

v  needs  system  support  to  carry  out  con¬ 
strained  design  processes  at  the  user’s 
operational  level. 

We  have  constructed  design  environ¬ 
ments56  to  support  the  modification  and 
construction  of  new  systems  from  sets  of 
predefined  components.  In  contrast  to 
simple  construction  kits,  our  design  en¬ 
vironments  incorporate  knowledge  about 
which  components  fit  together  and  how 
they  do  so,  and  they  supply  critics  that  rec- 
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ognize  errors  and  inefficient  or  useless 
structures.  Our  environments  can  deal 
with  multiple  representations  of  the  de¬ 
sign. 

Lessons  learned 

The  success  of  new  compute .  systems 
(the  Macintosh  may  be  the  best  example) 
isjudged  less  and  lesson  pr  icessing  speed 
and  memory  size  and  mote  and  more  on 
the  quality  of  communication  capabilities. 
We  have  learned  that,  to  be  successful, 
HCI  software  must: 

•  Take  advantage  of  technology.  Mod¬ 
ern  work'  tations  provide  new  technologi¬ 
cal  possibilities.  Yet  many  current  user  in¬ 
terfaces  are  still  teletype-oriented.  It 
requires  a  huge  design  and  imple¬ 
mentation  effort  to  reconceptualize  all 


software  to  take  advantage  of  the  new 
possibilities. 

•  Use  user-interface  construction  kits. 
User-interface  management  systems7  pro¬ 
vide  graphical  primitives  and  tools  to 
specify  dialogue  structures,  but  they  limit 
information  exchange  and  separate  the 
user  interface  from  the  application.  This  is 
a  reasonable  approach  for  some  prob¬ 
lems.  However,  for  the  kinds  of  problems 
we  try  to  solve,  such  as  intelligent  support 
for  human  problem-domain  communi¬ 
cation,  a  strong  separation  between  inter¬ 
face  and  application  is  not  feasible.  In 
these  systems,  the  user  interface  must  have 
extensive  access  to  the  state  and  actions  of 
the  application  system.  For  problems  of 
this  kind,  user-interface  construction  kits 
are  more  appropriate. 

User-interface  construction  kits  can  pro¬ 
vide  powerful  environments  for  rapid  pro¬ 
totyping  of  a  large  class  of  interfaces.  They 
provide  many  building  blocks  for  con¬ 
structing  high-quality  interfaces  at  a  rela¬ 
tively  low  cost,  and  object-oriented  archi¬ 
tectures  can  supply  unifotmity, 
extensibility,  and  incremental  develop¬ 
ment. 

User-interface  construction  kits  come 
close  (within  their  scope)  to  our  notion  of 
human  problem-domain  communi¬ 
cation.  Users  familiar  with  problem 
domains  but  inexperienced  with  comput¬ 
ers  have  few  pr  oblems  using  these  systems, 
while  computer  experts  unfamiliar  with 
the  pro'  I’-m  domains  could  not  exploit 
their  •  ower. 

The  major  shortcoming  of  large  con¬ 
struction  kits  is  that  they  do  not  help  the 
designer  construct  interesting  and  useful 
artifacts  in  the  application  domain.  In 
Crack,  for  example,  it  is  not  enough  to 
provide  design  units  —  kitchen  design  is 
more  than  placing  appliances.  Design  en¬ 
vironments  and  critics  are  needed  to  help 
users  construct  truly  interesting  artifacts; 
they  surpass  construction  kits  in  that  they 
incorporate  useful,  general  knowledge 
about  design. 

•  Provide  exploratory  environments. 
Users  do  not  know  what  they  want,  and  de¬ 
signers  do  not  understand  what  users 
need  or  will  accept.  The  onlv  viable 
strategy  for  HCI  software  is  incremental, 
evolutionary  development.  Initial  svstems 
must  be  built  to  give  users  something  con- 
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Framer  and  Crack 

Framer  and  Crack  are  design  environments.  Framer  supports  the 
construction  of  window-based  user  interfaces  and  Crack  supports 
cooperative  kitchen  design  Both  systems  incorporat e  and  illustrate  the 
research  issues  outlined  in  this  article 

The  basic  building  blocks  are  application-dependent  abstractions 
that  support  human  problem-domain  communication.  Framer  and 
Crack  incorporate  intelligent  Support  systems  and  offer  different  design 
strategies  such  as  design  with  basic  building  blocks  and  redesign  of 
prototypical  examples. 

Framer.  Figure  A  shows  a  screen  from  Framer,  an  enhanced  ver¬ 
sion  of  the  Symbolics  Frame-Up  tool.  Framer  offers  the  user  a  palette 
of  domam-onented  building  blocks,  and  supports  direct-manipulation 
interaction  in  the  work  area.  This  visual  interaction  style  is  especially 
appropnate  in  a  domain  in  which  visual  objects  are  designed  from 
visual  parts. 

In  addition  to  serving  as  an  application-oriented  construction  kit, 
Framer  has  a  small  rule  base  with  design  knowledge  about  relevant 
aspects  of  window-based  user  interfaces.  The  Praise  command  tells  a 
user  the  positive  aspects  of  a  design;  the  Suggest  Improvements  com¬ 
mand  criticizes  the  design ;  the  Explain  option  gives  some  rationale  for 
the  suggested  improvement. 

Framer  includes  a  catalog,  which  contains  several  prototypical  de¬ 
signs  that  can  be  praised  and  cntiqued  When  brought  into  the  work 
area,  the  user  can  modify  them  and  use  them  as  a  starting  point  for  re¬ 
design.  Prototypical  solutions  that  can  be  changed  and  refined  through 
redesign  are  important  enrichments  tor  designers  and  enlarge  their  de¬ 
sign  possibilities  Users  can  store  their  designs  in  the  catalog 

Without  Framer,  the  user  would  have  to  wnte  the  program  in  Figure 
B  to  generate  the  screen  layout  in  Figure  A.  Framer  generates  this  code 
automatically  An  experienced  user  can  then  modify  the  oode. 

Crack.  Cntics  are  another  type  of  intelligent  support  system  Cnocs 
let  users  pursue  their  own  goals,  intervening  only  if  they  discover  the 
solution  is.  according  to  their  knowledge,  inferior 


Empirical  observations  indicate  that  users  are  often  unwilling  to  learn 
more  about  a  system  than  they  need  to  solve  their  current  problem.  To 
cope  with  new  problems  as  they  anse,  a  critic  must  generate  advice 
that  is  tailored  to  the  user's  needs  and  the  current  situation.  This  re¬ 
moves  from  users  the  burden  of  helving  to  team  new  things  m  neutral 
settings  when  they  do  not  know  if  they  will  ever  use  them. 

Figure  C  shows  a  screen  from  Crack,1  a  critic  system  that  helps 
users  design  kitchens.  Similar  to  Framer,  it  provides  a  set  of  domain- 
specific  building  blocks  and  has  knowledge  about  how  to  combine 
them  into  useful  designs.  It  "looks  over  the  shoulder'  of  users  as  they 
design.  If  it  discovers  a  shortcoming  in  the  design,  it  offers  criticism, 
suggestions,  and  explanations  and  helps  users  improve  the  designs 
through  cooperative  problem  solving.  Crack's  objective  is  to  blend  the 
designer  and  the  computer  into  a  problem-solving  team  to  produce  bet¬ 
ter  designs  than  either  of  them  oould  working  alone. 

User  control.  Cntics  in  Crack  are  state-driven  condition-action  rules 
that  are  triggered  when  nonsatisfying  partial  designs  are  detected 
These  rules  are  activated  after  each  state  change  State  changes  are 
all  instance  creators  of  design  units  and  of  any  design-unit  manpula- 
ton  (like  move,  rotate,  and  scale).  An  unsatisfactory  solution  is  an  ar¬ 
rangement  of  design  units  that  violates  one  or  more  of  the  relators 
between  them. 

Crack  is  not  an  expert  system  that  dominates  the  design  process  by 
generating  new  designs  from  high-level  goals  or  resolving  design  con¬ 
flicts  automatically  Users  control  the  system's  behavior  at  all  tmes  and 
can  modify  its  knowledge  base  if  they  disagree  with  the  criticism. 

Crack  lets  the  user  control  the  finng  of  critics  at  three  levels:  All  cri¬ 
tiquing  can  be  turned  on  or  off,  individual  critics  can  be  enabled  or  dis¬ 
abled  ,  and  specific  relations  in  a  critic  can  be  modified .  When  critiquing 
is  turned  off  (the  default),  Crack  acts  like  a  construction  kit  with  no  de¬ 
sign  knowledge  When  critiquing  is  enabled,  all  cntics  are  active.  An  in¬ 
dividual  critic  can  be  disabled  if  a  user  does  not  like  its  criticism  or  if  its 
knowledge  has  been  assimilated  and  is  no  longer  needed  At  the 
lowest  level,  the  different  relational  tests  within  a  critic  can  be  replaced. 


A.  A  screen  from  Framer,  a  design  environment  for  window-based  interfaces. 
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For  example,  if  a  usee  doesnl  want  to  have  the  sink  in  front  o*  a  «<r 
dow,  the  in-f  ront-of  relation  can  be  replaced  with  another  retaDor,  sc**- 
as  no-relalion  or  ctose-to. 

Appropriate  applications.  The  critiquing  approach  s  best  sotted  tor 
id-defined  problem  areas  where  the  goal  is  to  satisfy,  rather  than  op¬ 
timize,  a  solution.  Kitchen  design  (as  an  area  of  architectural  design)  e 
still  an  ill-defined  problem  despite  the  existence  of  some  welLestab- 
lished  design  principles.  Architects  do  not  try  to  find  optimal  solutions 
to  design  problems  but  rather  make  trade-offs  within  a  solution  space 
that  is  bounded  by  external  constraints. 

Critics  can  be  classified  as: 

•  Active  or  passive.  Critics  can  activate  themselves  when  they  detect 
an  unsatisfactory  design  or  they  can  be  passive  and  wait  until  the  user 
asks  for  an  evaluation .  Active  criticism  early  in  the  design  makes  users 
aware  of  their  unsatisfactory  design  when  the  mistake  is  easier  to  cor¬ 
rect.  But  users  may  find  it  a  nuisance  to  have  someone  continuously 
critique  them  without  giving  then .  a  chance  to  develop  their  own  work. 
A  passive  critic  lets  the  user  request  an  evaluation  when  they  have 
completed  a  partial  design.  Active  critics  seem  to  be  suited  for  guiding 
novice  users;  passive  critics  seem  to  be  more  appropriate  for  interme¬ 
diate  users. 

•  Reactive  or  proactive .  Crack's  critics  are  reactive :  They  make  com¬ 
ments  about  what  the  user  has  done.  A  proactive  critic  plays  the  role  of 
an  adviser  by  suggesting  what  the  user  might  do  or  proposing  criteria 
which  the  user  should  consider.  For  example,  a  proactive  critic  in  Crack 
could  highlight  the  area  where  a  new  design  uni t  could  be  located  in  a 
partially  completed  design. 

•  Positive  or  negative.  Critics  can  either  praise  a  superior  design  or 
complain  about  an  inferior  design.  Critics  in  Crack  are  negative:  They 
complain  only  about  unsatisfactory  configurations  and  do  not  praise 
especially  useful  or  interesting  configurations.  Human  critics  are  both 
positive  and  negative. 

•  Local  or  global.  A  critic  s  granularity  determines  whether  it  is 
oriented  toward  local  aspects  of  a  partial  design  or  global  aspects  of 
the  total  design.  A  sink  critic  is  a  local  critic  because  it  is  concerned  with 
a  low-level  design  unit:  a  sink  A  work-triangle  critic  (the  work  triangle  is 


;v.  )  f  r  *.?  PROGRAM  r  RAME  WORK  EXAMPLE  1 
COMMANC-  Dir  kept 
COMMAND  TA&.E 

irarERiT  FROM  ‘cdoCuii  command"  "standard  arguments' 
'input  eritor  compatitxlny*) 

KBO  ACCELERATOR  P  NIL) 

STATE  VARIABLES  NIL 


PANES 

|  (PANE  1  DISPLAY 
(PANE  5  DISPLAY) 

(PANE-4  DISPLAY) 

(TITLE  TITLE  HEIGHT-IN-LINES  1 
REDISPLAY  AFTER-COMMANDS  NIL) 
(|menubar|  COMMAND-MENU  MENU-LEVEL 
:  TOP-LEVEL) 

(PANE-3  DISPLAY)) 


•CONFIGURATIONS 
'( (DW:MAIN 

(lAYOUT (DW::MAIN  :COLUMN  ROW  1  TITLE 
(menubar)  PANE-3) 

(ROW-1  :ROW  PANE- 1  PANE  S  PANE-4)) 

(SIZES 

(DW  MAIN  (TITLE  1  :UNES) 

(|menubar|  ASK-WINDOW  SELF 
:SIZE-FOR-PANE  |menu  bar|) 

:THEN  (ROW-1  :EVEN  )(PANE-3  :EVEN)) 
(ROW-1  (PANE-1  EVEN)  (PANE-5  :EVEN)  (PANE-4  EVEN)))))) 


Figure  B.  The  Lisp  program  for  the  screen  layout  in  Figure  A. 


the  center-front  distance  between  the  sink,  range,  and  refrigerator)  is 
a  more  global  critic  because  it  is  concerned  with  a  larger  portion  of  the 
design:  several  appliances.  A  kitchen  critic  is  a  global  critic:  It  is  con¬ 
cerned  with  the  look  of  the  entire  kitchen. 

Reference 

1 .  G.  Fischer  and  A  Morch,  "Crack:  A  Critiquing  Approach  to  Cooperative 
Kitchen  Design  ."  Proc  Inti  Coni  Intelligent  Tutonng  Systems.  ACM,  New 
York,  1988.  pp.  1/6-185. 


Fl£jre  C.  A  screen  from  Crack,  a  critic  system  for  kitchen  design 
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crete  lo  react  to.  This  strategy  must  be  sup¬ 
ported  bv  exploratory  programming  sys¬ 
tems  that  support  the  coevolution  of  speci¬ 
fications  and  implementations. 

Prototypes  replace  anticipation  (how 
will  the  system  behave?)  with  analysis  (how 
does  it  actually  behave?),  which  is  much 
easier  to  work  with.  Most  major  computing 
svstems  have  been  developed  with  exten¬ 
sive  feedback  from  their  actual  use  In  this 
wav  improvements  are  made  in  response 
to  discrepancies  between  a  system's  actual 
and  desired  states. 

We  know  that  writers  with  access  to  edi¬ 
tors  and  formatting  tools  are  increasingly 
willing  lo  modify  their  work.  Intelligent 
support  tools  in  exploratc  y  program¬ 
ming  environments  will  lower  the  cost  of 
making  changes,  so  designers  will  also 
start  to  experiment  —  thereby  gaining  ex¬ 
perience  and  insight  leading  to  better  de¬ 
signs 

Exploratory  environments  also  support 
reuse  and  redesign  But  anyone  who 
thinks  that  reuse  and  redesign  comes  for 
free  is  wrong  If  reuse  and  redesign  are 
great  ideas  and  if  they  are  easy  lo  master, 
whv  have  they  had  limited  success  so  far  in 
software  development?  Observation  of  de¬ 
signers  dealing  with  complex  software  sys¬ 
tems  has  revealed  one  reason:  These 
methodologies  are  not  adequately  sup¬ 
ported.  It  is  loo  expensive  to  change  a  sys¬ 
tem  or  explore  design  alternatives  in  most 
software  production  environments. 

•  Use  prototypes.  Static  specification 
languages  have  little  use  in  HCI  software 
design.  First,  detailed  specifications  do  not 
exist.  Second,  the  interaction  between  a 
system  and  its  user  is  highly  dynamic  and 
aesthetic,  aspects  that  are  difficult,  if  not 
impossible,  to  describe  with  a  static  lan¬ 
guage.  Successful  HCI  svstems  should  let 
users  play  with  the  prototvpe  systems  and 
discuss  their  design  rationale  A  prototvpe 
makes  it  much  easier  and  productive  for 
designers  and  users  to  coopoate  because 
users  do  not  have  to  relv  on  written  specifi¬ 
cations,  which  do  not  indicate  an  inter¬ 
face's  qtialiues. 

•  Promote  natural  communication.  Nat¬ 
ural  communication  is  more  than  the  abil¬ 
ity  to  communicate  in  natural  language;  it 
is  the  ability  to  engage  in  a  riinloguf.  When 
human  novicescommunicatc  with  human 
experts,  much  more  goes  on  than  just  a  re¬ 


quest  for  factual  information.  Novices 
may  not  be  able  to  articulate  their  ques¬ 
tions  without  the  experts'  help;  the  ex¬ 
perts'  advice  may  not  be  understood  with¬ 
out  further  explanation;  each  may 
hypothesize  that  the  other  misunder¬ 
stood;  experts  may  provide  information 
they  were  not  explicitly  asked  for. 

Natural  communication  needs  a  proper 
user  interface  to  support  it,  but  it  is  not  re¬ 
stricted  to  the  user  interface.  The  underly¬ 
ing  knowledge  base  must  contain  the 
needed  knowledge,  and  it  must  be  struc¬ 
tured  correctly. 

•  Help  the  user  make  intelligent  choices. 
Communication  can  be  described  in 
terms  of  the  speaker  and  the  listener  roles. 
The  speaker  presents  information,  per¬ 
haps  in  the  form  of  a  question  or  as  a  re¬ 
quest  foraction,  which  the  listener  tries  to 
understand.  In  general,  the  listener  must 


Concern  for  the  human 
must  equal  concern  for 
the  computer.  A  theory 
of  human  cognitive 
processes  should  drive 
the  new  communication 
developments. 

be  the  more  intelligent  agent  because  he 
must  not  only  understand  a  situation  as 
such  but  also  understand  how  the  speaker 
presents  it. 

In  HCI,  the  user  is  the  more  intelligent 
agent.  Therefore,  giving  the  user  the  ap¬ 
propriate  cues  is  the  essence  of  most  HCI 
designs:  The  context  provided  by  win¬ 
dows,  menus,  spreadsheets,  property 
sheets,  and  form  systems  lets  the  user 
choose  the  appropnate  next  step. 

Because  humans  and  computers  are  not 
alike,  designing  HCI  software  isa  problem 
not  only  of  simulating  human-to-human 
communication  but  of  engineering  alter¬ 
natives  in  the  domain  of  interaction-re¬ 
lated  properties.  Humans  do  not  have  a 
menu  on  their  forehead  of  the  commands 
they  can  execute  in  a  certain  context. 

•  Extend  the  design  knowledge  base. 
Why  hasn't  someone  like  Donald  Knuth 
written  a  book  with  prescriptions  for  build¬ 


ing  good  HCI  software?  Because  the  basis 
of  such  a  book  has  yet  to  be  created  by 
cognitive  science.  We  have  to  extend  the 
existing  knowledge  base  for  HCI.  Card, 
Moran,  and  Newell8  have  provided  some 
methodologies  and  principles  for  the  de¬ 
sign  of  systems  that  support  routine  cogni¬ 
tive  skills  whose  time  spans  fall  within  sec¬ 
onds.  But  these  quantitative  design 
methods  are  not  relevant  to  complex  sys¬ 
tems,  which  may  take  months  and  years  to 
learn  and  understand. 

An  interdisciplinaryapproach  isneeded 
to  increase  our  HCI  knowledge  base.  Con¬ 
cern  for  the  human  must  equal  concern 
for  the  computer.  A  theory  of  human 
cognitive  processes  should  drive  the  devel¬ 
opment  of  new  communication  capabili¬ 
ties.  We  need  design  principles  for  com¬ 
prehensible  systems  that  are  not  restricted 
to  the  evaluation  and  assessment  of  ex¬ 
isting  HCI  systems.  If  humans  are  the  fix 
point  of  future  HCI  systems,  the  designs 
must  be  based  on  cognitive  principles 
right  from  the  beginning. 

Challenges  ahead 

User-centered  designs,  comprehensible 
systems,  intelligent  support  systems,  and 
powt-ful  tools  to  augment  human  intel¬ 
ligence  are  the  main  goals  of  HCI  design. 
The  software  design  community  has  ac¬ 
cepted  these  goals  as  relevant,  and  con¬ 
siderable  progress  has  been  madeoverthe 
last  few  years.  But  big  challenges  lie  ahead: 

•  Focus  on  innovation.  Part  of  our  re¬ 
search  effort  should  be  directed  toward 
demonstrating  which  current  systems  are 
good  or  bad  because  this  gives  us  insight 
into  the  design  criteria  for  future  systems. 
But  the  main  challenge  lies  in  developing 
new,  innovative  systems. 

Restricting  our  effort  to  evolutionary 
improvement  of  current  systems  ignores 
the  history  of  HCI  over  the  last  decades, 
duringwhich  HCI  has  made  revolutionary 
steps  forward.  If  the  cost  of  developing 
HCI  software  is  to  be  reduced,  more  com¬ 
puter  support  must  be  supplied  lo  the  de¬ 
velopment  process.  Current  development 
occursnot  in  the  computer  but  in  people's 
heads;  it  is  not  documented  and  therefore 
cannot  be  analyzed. 

•  Perform  real  evaluations  If  the  pri¬ 
mary  approach  to  HCI  is  incremental  and 
evolutionary,  evaluation  of  existing  sys- 
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terns  is  an  important  activity.  The  chal¬ 
lenge  here  is  not  to  restrict  our  evaluations 
to  laboratorv  experiments  but  to  test  real 
users  doing  real  tasks  in  real  settings.  Ulti¬ 
mate  criteria  are  usefulness  and  usability 
for  real-wor'  1  purposes  and  therefore 
must  be  tested  in  the  real  world.  Validation 
and  verification  methods  from  other  soft¬ 
ware  domains  have  limited  use  in  HC1. 
Forma]  correctness  is  crucial,  but  it  is  by  no 
means  a  sufficient  measure  of  the  effec¬ 
tiveness  and  success  of  an  HCI  system. 

•  Accept  change.  We  have  to  accept  the 
empirical  truth  that  for  many  systems  re¬ 
quirements  cannot  be  stated  fully  in  ad¬ 
vance.3  In  many  cases,  they  cannot  even  be 
stated  in  principle  because  neither  design¬ 
ers  nor  users  know  them  in  advance.  The 
development  process  itself  changes  the 
designers'  and  users'  perceptions  of  what 
is  possible  and  increases  their  insights.  We 
have  to  accept  changing  requirements  as  a 
fact  of  life  and  not  condemn  them  as  a 
product  of  sloppy  thinking.  We  need 
methodologies  and  tools  that  support  and 
coordinate  the  process  of  change. 

•  Tailor  software.  One  crucial  shortcom¬ 
ings  of  computers  is  that  they  don’t  sup¬ 
port  the  notion  of  accomplishing  a  task  or 
purpose  that  the  user  chooses.  To  do  so 
would  require  software  that  is  truly  soft, 
which  means  that  the  behavior  of  a  system 
can  be  changed  without  major  reprogram¬ 
ming  and  without  specialists.  This  require¬ 
ment  is  critical  because  predesigned  sys¬ 
tems  are  too  rigid  for  problems  whose 
nature  and  specifications  change  and 
evolve. 

Thisgoal  doesnot  imply  transferring  the 
responsibility  of  good  system  design  to  the 
user.  It  is  probable  safe  to  assume  that  nor¬ 
mal  users  will  never  build  tools  of  the  qual- 
itva  professional  designer  can  achieve.  But 
a  question  for  future  research  is'  Should 
we  design  the  HCI  part  of  a  svstem  com- 
pletelv  or  should  we  develop  metasv stems 
that  let  users  alter  the  HCI  according  to 
their  needs'"  Should  svstems  be  adaptive  — 
should  thev  change  their  behavior  based 
on  a  model  of  the  user  and  the  task  (the 
idea  behind  our  critic  svstems)  —  or 
should  svstems  be  adaptable  bv  the  user 
( as  thev  must  be  to  support  reuse  and  rede¬ 
sign)" 

•  Provide  a  window  into  the  knowledge 
base.  It  is  insufficient  for  intelligent  sup¬ 


port  systems  tojust  solve  a  problem  or  pro¬ 
vide  information.  The  user  must  be  able  to 
understand  and  question  their  criticism. 
We  assume  that  users  will  not  ask  a  pro¬ 
gram  for  advice  if  its  expertise  cannot  be 
examined.  Designers  must  provide  win¬ 
dows  into  the  knowledge  base  and  reason¬ 
ing  processes  of  these  systems  at  a  level  that 
a  user  can  understand.  The  users  should 
be  able  to  query  the  computer  for  sugges¬ 
tions  and  explanations,  and  they  should 
be  able  to  modify  and  augment  the  critic’s 
knowledge. 

An  evaluation  of  Crack  demonstrates 
the  relevance  of  this  approach.  Crack  was 
used  by  an  architectural  designer  whocon- 
sidered  the  cooperative,  user-dominated 
approach  to  be  its  most  important  feature. 
He  felt  that  this  feature  set  Crack  apart 
from  expert-system  design  tools  that  often 
reduce  users  to  spectators.  In  the  current 


We  have  to  accept 
changing  requirements 
as  a  fact  of  life  and  not 
condemn  them  as  a 
product  of  sloppy 
thinking  Tools  should 
support  change. 

version  of  Crack,  we  have  deliberately 
avoided  equipping  the  sy  stem  with  its  own 
design  capabilities.  Whv  ?  Because  users  in¬ 
crease  their  knowledge  and  indepen¬ 
dence  by  working  with  svstems  that  do  not 
do  the  work  for  them  but  that  enable  them 
to  do  it  themselves.  Too  much  assistance 
and  t<x)  manv  automatic  procedures  can 
reduce  users'  motivation. 

•  Improve  cooperative  problem-solving 
svstems.  Current  intelligent  support  sys¬ 
tems  like  Framer  and  Crack  are  one-shot 
affairs.  They  give  advice,  but  that  advice  is 
not  a  starting  point  for  cooperative  prob¬ 
lem  solving  Human  advisory  dialogues'1 
are  judged  successful  when  thev  allow 
shared  control  of  the  dialogue.  Our  svs¬ 
tems  should  be  designed  to  manage  errors 
and  trouble.  No  system  can  be  designed  to 
be  totally  foolproof.  The  problem  in  HCI 
is  not  simple  that  difficulties  in  communi- 
catingarise  that  donoioccurin  human-to- 


human  communication  but  that,  when 
the  inevitable  troubles  do  arise,  the  same 
resources  are  not  available  for  their  detec¬ 
tion  and  repair.  Errors  should  not  cause  a 
breakdown  of  the  interaction;  thev  should 
be  regarded  as  an  integral  part  of  the 
process  of  accomplishing  a  task.  The  goal 
of  a  cooperative  endeavor  is  not  to  find 
fault  or  to  assess  blame  but  to  get  the  task 
done. 

•  Recognize  design  conflicts.  As  is  true 
for  most  real-world  design  tasks,  there  is 
no  optimal  solution  for  HCI,  onlv  trade¬ 
offs.  A  challenge  for  the  future  is  to  resolve 
these  design  conflicts.  In  our  research  ef¬ 
forts,  we  will  concentrate  on  the  following 
trade-offs: 

•  How  do  we  balance  the  effort  and  the 
large  training  costs  necessary  for  learning 
a  complex  interface  with  the  power  of  ex¬ 
tensive  functionality  "  It  is  important  that 
we  explore  techniques  that  reduce  the 
cognitive  costs  (such  as  learning  on 
demand  and  human-problem  communi¬ 
cation). 

•  How  do  we  make  computer  svstems 
useful  and  usableat  the  same  time?  Useful 
computers  must  be  complex  and  have  rich 
func’  "inalitv  because  they  must  model  the 
abstractions  of  manv  domains,  but  it  is 
hard  to  make  complex  svstems  usable.  In¬ 
telligent  support  systems  promise  to  par¬ 
tially  resolve  this  design  conflict. 

•  How  do  we  achieve  high  speed  and 
convenience  of  use  (power)  for  the  expe¬ 
rienced  user  and  at  the  same  time  achieve 
ease  of  learning  and  use  for  the  novice  and 
the  casual  user?  Adaptive  and  adaptable 
systems  will  more  closely  accommodate 
the  needs  of  the  individual  user. 

•  How  do  we  separate  dialogue  manage¬ 
ment  from  the  application  (loenhance  re¬ 
usability  and  uniformity)  and  vet  retain 
application-specific  semantics?  User-inter- 
face  toolkits,  UIMSs.and  human  problem- 
domain  communication  provide  differ¬ 
ent  answers  to  this  question. 

•  How  do  we  ensure  the  quality  of  HCI 
software  and  minimize  the  costs  of  its  de¬ 
velopment?  Reuse  and  redesign  will  be  an 
absolute  necessity  for  dealing  with  this  de¬ 
sign  conflict. 

•  How  do  we  fit  new  systems  comfortablv 
into  people’s  lives  and  at  the  same  ume 
dramaucallv  change  the  wav  thev  live  and 
work?  Incremental  learning  needs  to  be 
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enhanced  to  expose  users  to  systems  that 
have  a  low  threshold  (it  is  easy  to  get 
started)  and  a  high  ceiling  (the  limitations 
of  the  systems  do  not  show  up  immedi¬ 
ately). 

New  formalisms  and  new  tools  have 
helped  us  augment  human  intel¬ 
ligence.  Computers  used  in  the 
right  wav  are  a  unique  opportunity  to  lake 
another  big  step  forward,  to  create 
cooperative  systems  in  which  humans  can 
achieve  more  than  if  thev  were  working 
alone.  HC.l  software  is  needed  to  exploit 
this  potential. 

Creating  belter  HCI  software  will  have  a 
major  effect  on  software  engineers  them¬ 
selves  because  their  main  activity  is  design¬ 
ing  for  mostly  ill-structured  problems.  In¬ 
telligent  computer-support  systems  and 
good  interfaces  are  crucial  for  improving 
the  productivity  of  the  software  engineer 
and  for  increasing  the  quality  of  the  soft¬ 
ware  product.  The  cost  of  hardware  and 
software  in  future  systems  will  be  small 
compared  with  the  cognitive  costs  occur¬ 
ring  in  the  development,  comprehension, 
and  use  of  complex  systems.  ❖ 
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